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ABSTRACT 


This  annotated  briefing  discusses  the  security  issues  of  integrating  into  the  MITRE  network 
architecture  an  implementation  of  an  X.400  based  message  handling  system  (MHS). 
Background  concerning  both  the  MITRE  Open  Systems  Interconnection  (OSI)  integration 
project  and  X.400  is  given.  Threats,  vulnerabilities,  and  countermeasures  are  then  discussed 
Finally,  recommendations  for  integrating  an  MHS  into  the  MITRE  networks  are  presented. 
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Message  Handling  System 
(X.400) 

Threats,  Vulnerabilities,  and 
Countermeasures 


MflRE 


This  briefing  discusses  the  security  issues  of  integrating  into  the  MITRE  network 
architecture  an  implementation  of  a  message  handling  system  (MHS)  as  described  in  the 
International  Telegraph  and  Telephone  Consultative  Committee  (CCITT)  "Data 
Communication  Networks  Message  Handling  Systems,  Reconunendations  X.4(X)-X.420." 
The  integration  of  a  service  includes  the  opoation  of  the  sovice  within  MITRE  networics 
and  across  the  MITRE  security  boundary.  (The  security  boundary  is  defined  in  later  slides.) 
Threats,  vulnerabilities,  and  countermeasures  are  discussed. 
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Outline 


•  Project  background 

e  MHS  definitions  and  concepts 

e  Definitions  of  security  terms 

e  Scope  and  approach  taken  in  conducting  security 
anai^is 

e  General  security  Issues 

e  Specific  X.400  threats,  vulnerabilities,  and 
countermeasures 

e  Summary  and  recommendations 


The  outline  for  the  briefing  is  as  follows.  First,  background  concerning  the  project  for  which 
this  work  was  conducted  is  given.  This  is  followed  by  an  overview  of  MHS  definitions  and 
concepts.  Then,  definitions  of  die  terms  "direat,”  "vulneralnlity,"  and  "countermeasure"  are 
given.  Following  these  definitions,  the  scope  and  approach  taken  to  identify  security  issues 
concerning  the  integration  of  an  MHS  are  then  presented.  General  security  issues  that  relate 
to  the  integration  of  any  service  across  the  MTlllE  securify  boundary  are  then  discussed. 
Finally,  these  MHS-specific  security  issues  and  dieir  countermeasures  are  identified  followed 
by  a  summary  and  recommendations. 


Project  Context 


•  MITRE  OSI  Integration  Project 

-  Make  MITRE  a  national  center  of  excellence  for  OSI 

-  Integrate  OSI  services  Into  MBTRE's  current  network 
arcnhecture 

-  Strengthen  MITRE'S  sponsor  work  program  In  the 
open  systems  area 

e  What  are  the  security  Issues  of  Integrating  OSI  services? 

e  Specifically,  what  are  the  security  Issues  of  Integrating 
x!400? 

-  Integration  must  result  In  messaging  that 

•  Introduces  no  new  security  flaws 

•  Raises  the  current  security  baseline 


This  work  was  conducted  for  the  MITRE  Open  Systems  Interconnection  (OSI)  Integration 
Project  The  purpose  of  this  project  is  to: 

1.  make  MITRE  a  center  of  excellence  for  OSI, 

2.  integrate  OSI  services  into  MITRE's  network  to  bodi  enhance  corporate  network 
services  and  to  facilitate  the  first  goal,  and 

3.  strengthen  MITRE's  sponsor  work  program  in  the  open  systems  area  using  the 
experience  and  resources  of  the  project 

The  first  two  services  that  the  MITRE  OSI  Integration  project  is  planning  to  integrate  are 
X.4()0,  a  message  handling  system  service,  and  X.5()0,  a  ctirectory  service.  Before 
integrating  these  services,  however,  the  environment  that  MITRE  operates  within  must  be 
considered.  MITRE  must  protect  its  networks  and  electronic  information  firom  accidental 
release  and  outside  attacks.  Therefore,  the  security  issues  of  integrating  any  new  service 
must  be  investigated  before  integrating  that  service.  In  preparation  for  integrating  the  X.4()0 
MHS  into  the  MITRE  network  architecture,  this  briefing  discusses  the  security  issues 
investigated  regarding  the  X.4()0  integration.  During  this  investigation,  a  determination  had 
to  be  made  as  to  whether  or  not  die  integration  of  X.4(X)  would  introduce  new  security  flaws. 
In  fact,  the  current  security  baseline  should  be  raised  (some  existing  flaws  should  be 
eliminated). 
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This  slide  depicts  the  target  security  architecture  for  access  from  and  to  external  networks.  A 
frlteiing  router  that  allows  only  TCP/IP  and  TP4/CLNP  packets  through  is  located  between 
the  internal  MITRE  production  network  and  external  networks.  Through  filtering,  this  router 
establishes  the  security  boundary  between  MITRE  and  the  external  networks.  A  limited  set 
of  internal  boundary  hosts,  arable  of  processing  both  TCP  and  TP4  packets,  are  allowed  to 
connect  through  the  router.  Other  hosts  within  MITRE  must  connect  to  these  boundary  hosts 
before  gaining  access  to  external  networks. 
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Security  Architecture 
Current  External  Network  Access 


Currently,  only  TCP  traffic  is  allowed  to  pass  through  the  securiQ^  boundary.  TP4  (OSI) 
traffic  is  not  allowed.  As  a  result,  we  currently  have  disjoint  internal  and  external  OSI 
resources  operating  in  pilot  efforts  of  the  MITRE  OSI  Integration  Project  The  term 
"disjoint"  means  that  the  internal  pilot  hosts  do  not  communicate  with  the  external  pilot 
hosts.  There  is  a  concurrent  ongoing  effort  addressing  OSI  packet  filtering  and  routing  to 
enable  TP4  traffic  to  flow  across  the  boundary.  If  this  work  is  not  complete  when  the  project 
is  ready  to  deploy  MHS  across  the  boundary,  dual  stacked  (TCP  and  TP4)  hosts  will  be  used 
to  pass  X.400  messaging  traffic  over  TCP  across  the  boundary  as  an  interim  transition  step. 

A  phased  transition  plan  is  described  on  the  next  slide. 
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Pha.>dS  for  Integrating  X.400  and  X.500 


•  PtWM  I:  Dia|oint  X.400  and  X500  intamal  and  axtamal 

pileta 

•  Phaaall;  X.400  aarvioa  ptovidad  acroaa  boundary  via 

:CP/IP 

•  Phaaalll:  X.500  aeoaaa  acroaa  tha  boundary  via  TCP/IP 

•  Ptiaaa  iV:  Lovfar  iayar  capabiiitiaa,  TP4  A  CLNP,  acroaa 

boundary 

•  PhaaaV:  Fuii  OSI  alack  ci^MdrHitiaa  acroaa  boundary  with 

intarmadiata  hop  through  axtamal  OSI  pilot  boat 
aikninatad 


In  transitioning  to  the  target  architecture,  a  phased  approach  is  being  taken.  The  &st  phase 
involves  upper  layer  OSI  (X.400  and  X.S00)  pilot  hosts  that  exist  both  intemaUy  and 
externally.  The  internal  hosts  communicate  with  each  other,  and  the  extomal  host  can 
communicate  with  other  external  OSI  hosts.  However,  the  pilot  hosts  in  this  phase  do  not 
send  traffic  across  the  boundary.  The  second  phase  is  to  establish  X.4(X)  traffic  across  the 
boundary  using  TCP/IP  in  the  lower  layers,  llie  third  phase  is  to  add  X.5(X)  traffic.  The 
second  and  diiid  phase  can  occur  concurrently.  Phase  four  allows  TP4  transport  and  CLNP 
network  layer  traffic  to  cross  the  boundary.  Phase  five,  the  target  architecture,  is  the  atkiition 
of  full  OSI  stack  capabilities  at  both  the  boundary  hosts  and  the  filtering  gateway  which 
allows  the  intermediate  hop  tiirough  the  external  OSI  pilot  host  to  be  eliminated.  At  this 
point,  we  will  also  begin  investigating  additional  OSI  services  which  will  require  external 
access  (e.g..  File  Transfer,  Access,  and  Management  (FTAM)). 
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MHS  Functional  Model 


Now  that  some  project  background  has  been  given,  some  concepts  related  to  X.400  will  be 
given  in  preparation  to  discussing  threats,  vulnerabilities,  and  countermeasures  specific  to 
X.400. 

This  slide  depicts  the  functional  model  of  an  MHS.  The  heart  of  an  MHS  is  the  message 
transfer  system  (MTS).  The  message  transfer  system  is  responsible  for  relaying  messages 
within  the  MHS  so  that  they  can  be  delivered  to  the  appropriate  user.  The  functional  entity 
that  performs  the  transfers  is  a  message  transfer  agent  (MTA). 

MTAs  transfer  messages  to  each  other  via  the  message  transfer  protocol  (PI).  MTAs  provide 
access  to  the  MTS  by  MHS  components  external  to  the  MTS  via  the  MTS  access  protocol 
(P3).  These  components  include  message  stores  (MS)  and  user  agents  (UA). 

A  user  interfaces  with  a  UA  to  gain  access  to  the  MHS  to  send  messages  to  other  users.  A 
UA  can  cither  directly  access  the  MTS  via  P3  or  can  indirectly  access  the  MTS  via  an  MS. 
Access  to  the  MS  is  provided  through  the  MS  access  protocol  (P7).  The  MS  stores  messages 
that  the  user  is  submitting  to  the  MTS  and  messages  diat  are  to  be  delivered  to  the  user. 

The  higher  level  protocol  that  provides  messaging  between  users  through  UAs  and  makes 
use  of  PI,  P3,  and  P7  is  the  interpersonal  messaging  protocol  (P2). 
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Not  depicted  in  the  functional  model,  but  included  in  the  recommendation,  is  an  access  unit 
(AU).  An  AU  links  another  communication  system  (e.g.,  a  physical  delivery  system  or  the 
telex  network)  to  the  MTS.  Security  issues  relating  to  AUs  were  not  addressed  at  this  time, 
and  AUs  will  not  be  used  in  the  initial  deployment  of  an  X.400  implementation. 

Although  the  functional  model  depicts  the  UA,  the  MS,  and  the  MTA  as  being  distinct 
entities,  it  is  possible  for  them  to  be  physically  coresident 


Abstract  Definitions 


•  Object 

-  Functional  entity  that  Interacts  with  other  objects 

-  Examples:  MTS,  MTA,  MS,  UA 

-  Different  from  COMPUSEC  object 

•  Port 

-  Point  at  which  objects  interact 

-  Must  be  bound  before  objects  Interact 

-  Examples:  submission,  deiivery,  administration, 
transfer,  retrieval.  Indirect  submission 

•  Operation 

-  A  task  that  one  object  carries  out  at  another’s  request 

-  Usually  requires  arguments 

-  Examples:  bind,  message  submission,  unbind 


In  discussing  the  behavior  of  the  MHS  functional  model,  the  recommendation  gives  a 
number  of  abstract  definitions.  For  example,  there  is  a  concept  of  an  object  An  object  is  a 
functional  entity  that  interacts  with  other  objects.  Examples  of  objects  are  an  MTS,  an  MTA, 
an  MS,  and  a  UA. 

For  purposes  of  clarification,  the  MHS  definition  of  object  is  different  firom  the  computer 
security  (COMPUSEC)  definition  of  object  A  COMPUSEC  object  is  a  container  of 
information  and  is  accessed  by  subjects.  The  COMPUSEC  definition  of  subject  is  closo'  to 
the  MHS  definition  of  object  COMPUSEC  subjects  can  interact  with  each  other  and  act 
upon  COMPUSEC  objects. 

Objects  have  ports  that  must  be  bound  to  ports  of  a  similar  type  at  another  object  in  order  for 
the  objects  to  interact  Examples  of  ports  include  ports  for  submission,  delivoy, 
administration,  transfer,  retrieval,  and  indirect  submission. 

An  operation  is  a  task  that  one  object  carries  out  at  the  request  of  another  object  An 
operation  usually  requires  the  initiator  to  supply  arguments.  Examples  of  operations  include 
bind,  message  submission,  and  unbind. 
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This  slide  depicts  the  various  objects  and  ports  of  an  MHS.  Individual  ports  are  defined  as 
follows: 

A  retrieval  port  allows  a  user  agent  to  retrieve  a  message  from  an  MS. 

An  indirect  submission  port  allows  a  UA  to  sulnnit  a  message  to  an  MS  for  submission  to  an 
MTA. 

An  administration  port  allows  a  UA  to  change  administration  information  held  at  the  MS  and 
the  MTA  concerning  the  user  associated  with  the  UA. 

A  delivery  port  allows  an  MS  to  accept  delivery  of  a  message  from  an  MTA  on  behalf  of  a 
UA. 

A  submission  port  allows  an  MS  to  submit  a  message  to  an  MTA  on  behalf  of  a  UA. 

A  transfer  port  allows  one  MTA  to  transfer  a  message  to  another  MTA. 

In  die  absence  of  an  MS,  die  UA  can  direcdy  access  the  MTA  via  P3  using  the  delivery, 
submission,  and  administration  ports. 
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Ports  and  Operations 


I 

I 

I 


•  Submission  and  indirect  submission 

-  Message  submission 

-  Probe  submisston 

-  Cancel  deterred  delivery 

-  Submission  control 
e  Delivery 

-  Message  delivery 

-  Report  delivery 

-  Delivery  control 
e  Administration 

>  Register 

-  Change  credentials 


For  each  port  within  an  MHS,  a  number  of  operations  can  take  place  across  that  port 
slide  lists  the  operations  associated  with  a  particular  port 
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MHS 

Ports  and  Operations  (Concluded) 


•  Transter 

-  Message  transfer 

-  Probe  transfer 

-  Report  transfer 
e  Retrieval 

-  Summarize 

-  List 

-  Fetch 

-  Delete 

-  Register>MS 
>  Alert 


This  slide  continues  to  list  the  operations  associated  with  a  particular  port 


MHS  Security  Services 


•  Security  services  outlined  In  recommendation  Include 

-  Authentication  services 
Data  confidentiality  services 

-  Data  Integrity  services 

-  Nonrepudiation  services 

e  Security  services  are  encryption  based 
a  Security  services  are  "optional  additional" 

-  Optional:  users  do  not  need  to  select  them 

-  Additional:  Implemerrtor  does  not  need  to  supply 
them 

e  Community  does  not  have  clear  direction  concerning 
security  services 


To  address  the  securiQr  threats  that  will  be  identified,  the  X.400  recommendation  outlines  a 
number  of  security  services.  These  security  services  include  authentication  services,  data 
confidentialiQ^  services,  data  integrity  services,  and  nonrepudiation  services.  These  security 
services  are  employed  via  encryption  and  may  involve  die  exchange  of  keys. 

The  recommendation  categorizes  the  security  services  as  being  "optional  additional."  The 
term  "optional"  indicates  that  the  users  of  the  MHS  or  MTS  do  not  need  to  select  diese 
services  when  transferring  messages.  The  term  "additional"  indicates  that  the  services  are 
not  required  to  be  supplied  with  the  implc -‘.lentation  by  the  vendor.  Therefore,  availability  of 
these  security  services  cannot  be  counted  upon  to  provide  countermeasures  against  identified 
threats  and  vulnerabilities. 

In  addition  to  the  potential  absence  of  these  securiQr  services,  a  clear  direction  by  various 
MHS  communities  towards  the  use  of  the  security  services  has  not  been  made.  Alternatives, 
such  as  Pre-Message  Security  Protocol  (PMSP),  Message  Security  Protocol  (MSP),  and 
Privacy  Enhanced  Mail  (PEM),  will  be  considered  in  the  future  to  provide  enhanced  security 
services. 
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MHS  Use  of 

Directory  Services  (X.500) 


•  CafMbillties 

-  UMr<frlMidly  naming 

•  Directory  nama  is  mapped  to  address 

-  Distribution  lists 

•  Directory  stores  membership  of  group 

-  Recipient  UA  c^Mdsillties 

•  Directory  stores  capabilities  of  UA 

-  Authentication 

•  Directory  stores  authentication  information  of 
MHS  functionai  entity 

-  Routing 

•  Dlrectoiy  may  be  used  to  hold  MTA  routing 
Information 


The  directory  de^ed  by  the  X.500-Series  of  Recommendations  provides  capabilities  that 
can  be  used  in  message  handling.  These  csQ}abilities  fall  into  the  following  four  categories: 

1.  User-Mendly  naming:  The  originator  or  recipient  of  a  message  can  be  identified  by 

a  directory  name  rather  than  a  machine-oriented  address.  The  MHS  can  derive  the 
address  firom  the  directoiy  name  by  consulting  the  directory.  ' 

2.  Distribution  lists  (DLs):  A  DL  can  be  a  group  whose  membership  is  stored  in  the 
directory.  The  originator  simply  supplies  the  name  of  the  list,  and  the  MHS  can 
obtain  the  directory  names  of  the  individual  recipients  by  consulting  the  directory. 

3.  Recipient  UA  capabilities:  Capabilities  of  a  UA,  such  as  deliverable  encoded 
information  Q^pes,  deliverable  content  types,  and  maximum  content  length,  can  be 
stored  in  a  directoiy  entry.  Die  MHS  can  obtain  these  capabilities  by  consulting  the 
directory. 

4.  Authentication:  Authentication  information  required  to  establish  the  identity  of  two 
functional  entities  prior  to  communication  can  be  stored  in  tiie  directory. 
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5.  Routing:  There  is  ongoing  work  to  standardize  representations  of  MTA  routing 
information  ’n  an  X.500  directory.  This  should  improve  the  management  and 
scalability  of  MTA  routing  tables. 

Security  implications  of  X.500  integration  have  not  been  investigated  at  this  time.  X.S00 
security  will  be  reviewed  in  a  separate  X.500  security  evaluation. 


Definitions 


•  Threat 

-  An  expression  of  Intent  to  cause  harm 

-  Threat  action 

•  An  action  taken  to  cause  harm 

-  Undesirable  outcome 

•  Caused  by  a  sequence  of  threat  actions 

e  Vulnerability 

-  The  property  of  being  open  to  attack  or  damage 
e  Countermeasure 

-  A  feature  that  reduces  or  eliminates  the  posstolllty 
of  a  vulnerability  from  being  exploited  and  an 
undesirable  outcome  from  occurring 


Now  that  project  background  and  MHS  information  have  been  presented,  some  security 
concepts  can  now  be  discussed.  First,  the  terms  "threat,”  "vulnerability,"  and 
"countenneasuie"  are  defined. 

Several  related  concepts  are  bundled  together  into  the  term  "threat"  A  threat  can  be  an 
expression  of  intent  to  cause  harm  (e.g.,  burglary).  It  can  also  be  an  action  taken  to  cause 
harm  (e.g.,  surveillance).  It  can  also  be  die  undesirable  outcome  that  results  from  a  sequence 
of  actions  taken  to  cause  harm  (e.g.,  loss  of  assets). 

A  vulnerability  is  the  property  of  being  open  to  attack  or  damage  (Le.,  an  undesirable 
outcome).  For  instance,  an  luilocked  door  makes  a  house  vulnerable  to  the  threat  of  burglary. 

A  countermeasure  is  a  feature  that  reduces  or  eliminates  the  possibility  of  a  vulnerability 
from  being  exploited  and  an  undesirable  outcome  from  occurring.  For  instance,  a  deadbolt 
lock  makes  a  house  less  vulnerable  to  the  threat  of  burglary. 
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Scope  of  Security  Analysis 


other 

applications 

iiiiilx.500 

other 

applications 

lower 

layer 

protocols 

lower 

layer 

protocols 

operatiB 

K  system 

operatii 

ig  system 

hardware  pfaUfarm  hardware  ptatform 


•  Llmn«d  to  the  protocols  and  services  defined  in  the  X.400 
aeries  of  recommendations 

e  Did  not  Include  an  analysis  of 

-  OperMhig  system  or  hardware  platform 

-  X.500  or  other  i^iplfcations 

-  Lower  layer  networking  protocols 


Before  discussing  the  analysis  and  results,  the  scope  of  the  analysis  and  the  approach  taken  in 
performing  the  analysis  must  be  presented. 

The  scope  of  the  effort  was  limited  to  investigating  those  security  issues  that  pertain  to  the 
protocols  and  sovices  defined  in  the  X.400  series  of  recommendations.  The  areas 
considered  are  the  greyed  boxes  and  the  dashed  line  between  them  (representing  the  PI,  P2, 
P3,  and  P7  protocols). 

The  analysis  did  not  consider  risks  relating  to  the  operating  system  (except  to  a  minimal 
extent),  the  hardware  platform,  X.500,  other  applications,  and  the  Iowa*  layer  networking 
protocols.  Networking  vulneraAnlities  not  addressed  include,  for  example,  eavesdropping. 
However,  there  are  no  new  networking  related  vulnerabilities  introduced  with  the  use  of 
X.400  that  do  not  exist  with  current  messaging. 
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Scope  of  Security  Analysis 
(Concluded) 


•  Assumed  classified  data  was  not  present 

-  No  analysis  of  covert  channels 

-  No  anal^s  of  mandatory  access  control  violations 
e  Addressed  direct  users  of  the  MHS 

-  Did  not  consider  risks  from  Indirect  users  using  accMS 
units  for 

•  Physical  delivery  services 

•  Teiematlc  services 


The  analysis  also  assumed  that  classified  data  was  not  present  on  MTTRE  networks  or 
systems  connected  to  those  networks  since  this  is  against  MTTRE  security  policy. 

Therefore,  there  was  no  analysis  of  possible  covert  charmels  or  mandatory  access  control 
violations. 

Other  vulnerabilities  not  considered  were  those  related  to  indirect  users  since,  initially,  X.400 
wiU  not  be  configured  to  have  these  users  when  integrated  into  MTTRE  networks.  Indirect 
users  include  those  users  who  require  physical,  rather  than  electronic,  delivery  of  their 
messages,  or  users  that  enqrloy  telematic  sovices  to  recdve,  for  example,  voice  mail. 
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Approach  to  Security  Analysis 


•  Identify  where  an  Implementation  could  potentially 
create  vulnerabilities 

-  In  general 

-  With  respect  to  the  recommendations 
e  General  threats  and  vulnerabilities 

-  Derived  from  ISO-7498-2  and  the  TCSEC 
e  Specific  threats  and  vulnerabilities 

-  CCITT  Recommendations  X400  -  X.420  were  studied 

•  Encompasses  all  recommended  message 
handling  elements  of  service 

•  Individual  Implementations  may  address  many  of 
the  identified  vulnerabilities 


The  r^rproach  taken  in  perfonning  the  security  analysis  was  to  identify  where  an 
implementation  could  potentially  create  vulnerabilities  once  integrated  into  the  MITRE 
networks.  The  analysis  was  conducted  at  two  levels.  First,  threats  and  vulnerabilities  that 
could  arise  with  the  introduction  of  any  new  service  were  analyzed.  These  threats  and 
vulnerabilities  were  derived  from  I irformation  Processing  Systems  -  Open  Systems 
Interconnection  -  Basic  Reference  Model  -  Part  2:  System  Architecture  (ISO-7498-2)  and 
the  Trusted  Computer  System  Evaluation  Criteria  (TCSEC). 

The  second  level  of  the  approach  was  to  identify  threats  and  vulnerabilities  specific  to  MHS 
by  thoroughly  searching  CCITT  recommendations  X.400  through  X.420  for  possible  security 
issues.  These  recommendations  encompass  all  aspects  of  message  handling  elements  of 
service.  Individual  implementations  have  not  yet  been  reviewed;  however,  we  expect  that 
specific  implementations  will  address  many  of  the  identified  vulnerabilities. 
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In  investigating  the  specific  vulnerabilities,  the  different  paths  that  an  MHS  operation  (e.g., 
message  submission)  and  acconqumying  data  (e.g.,  die  message)  could  take  within  die  NDIS 
were  tdso  considered.  One  path  is  a  strictly  internal  one.  A  request  for  an  operation  can  be 
initiated  within  MITRE  and  responded  to  widiin  MITRE.  Other  requests  could  be  initiated 
within  MITRE  but  be  responded  to  externally.  Hnally,  requests  could  be  initiated  externally 
and  be  responded  to  internally.  Although  the  first  two  paths  are  important,  the  external  to 
internal  pi^  poses  the  highest  risk  to  MITRE  and  must  be  consider^  carefully.  (The 
consideration  of  a  strictly  external  path  was  not  within  die  scope  of  diis  task.) 

The  boxes  in  grey  represent  elements  that  are  optional.  The  shadowed  boxes  rqiresait 
elements  of  which  there  could  be  one  or  several. 


20 


General  Threats 


•  Undesirable  outcomes 

-  Modification 

-  Disclosure 

-  Denial  of  service 
e  Threat  actions 

-  Masquerade 

-  Resequencing 

-  Repudiation 


There  are  a  number  of  general  threats  that  exist  for  any  service  that  is  to  be  integrated  (where 
"service"  includes  OSI  services,  other  networking  software,  and  other  applications).  The 
three  major  types  of  undesirable  outcomes  an  attacker  might  seek  to  achieve  include 
modification,  disclosure,  and  denial  of  service.  Modification  is  the  unauthorized  altering  of 
data,  which  includes  changing,  adding,  or  deleting  data.  Disclosure  occurs  when  a  subject 
reads  data  without  proper  authorization.  Denial  of  service  is  when  a  feature  or  system  is 
rendered  unavailable. 

For  each  of  these  outcomes,  a  variety  of  threat  actions  are  applicable.  These  threat  actions 
include  masquerade,  resequencing,  and  repudiation.  Masquerade  is  when  a  subject  (e.g., 
host,  user)  pretends  to  be  some  other  subject  Resequencing  happens  when  the  ordering  of 
the  data  is  changed.  Repudiation  is  when  a  subject  falsely  denies  having  eitiier  sent  or 
received  data. 

(This  list  of  threats  is  derived  fi’om  ISO  1 49S-2  Jrrformtion  Processing  Systems  -  Open 
Systems  Interconnection  -  Basic  Reference  Model  -  Part  2:  System  Architecture.) 


21 


Exploitation  of  Vulnerabilities 


•  Vulnerabilities  can  be  exploited  through  any  service  via 

-  Malicious  code  within  the  service 

•  Trojan  horses 

•  Viruses 

•  Worms 

-  Malicious  code  external  to  the  service 

•  Other  applications 

•  User  processes 

•  System  processes 

-  Errors 

•  Administrative  errors 

•  User  errors 

•  Software  bugs 


The  general  threats  described  previously  can  occur  through  the  exploitation  of  vulnerabilities 
specific  to  a  service.  For  any  service,  the  foUowing  goiera!  sources  could  exploit  service 
vulnerabilities.  Within  the  service  source  code,  malicious  code  could  exist  that  iiiq)leinented 
trojan  horses,  viruses,  and  worms.  External  to  the  code,  malicious  software  within  other 
applications,  user  processes,  or  system  processes  could  take  advantage  of  supplied  features  or 
a  poor  design  witl^  the  service  to  exploit  these  vulnerabilities.  Hnally,  errors  such  as  those 
committed  by  system  administrators,  users,  and  the  vendor  of  the  service  could  result  in  the 
unintentional  exploitation  of  a  vulnerability. 
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General  Assurance  Techniques 


•  Use  NSA  evaluated  or  assessed  products 

•  Obtain  source  code  based  on 

-  Availability  of  source  code  license 

-  Cost 

-  Maturity  of  product 

-  Reputation  of  vendor 

e  If  obtained,  inspect  source  code  looking  for 

-  Maintainability 

-  Modular,  structured  code 

-  Enforcement  of  least  privilege 

-  No  extraneous  features 

-  No  *1>ack  doors"  (e.g.,  master  passwords) 


For  vulnerabilities  specific  to  a  service,  countermeasures  can  often  be  implemented  to 
prevent  or  limit  the  chance  of  those  vulnerabilities  being  exploited.  For  any  service,  a 
number  of  assurance  techiuques  could  be  instituted  tiiat  would  ensure  tiiat  countermeasures 
have  been  correctly  implemented  and  carmot  be  easily  circumvented  and  that  no  malicious 
code  has  been  incorporated  into  the  system. 

One  assurance  techiuque  is  to  use  products  evaluated  by  the  National  Security  Agency  or 
assessed  by  some  other  orgaruzation.  If  possible,  source  code  ^ould  be  obtained.  To  obtain 
source  code,  a  license  must  be  available  for  purchase  firom  the  vendor.  The  decision  to 
obtain  source  code  also  depends  on  the  cost  of  the  code,  whether  or  not  the  code  is  expected 
to  undergo  many  revisions,  and  tiie  reputation  of  tiie  vendor.  If  little  is  known  about  Ae 
quality  of  the  work  produced  by  the  vendor,  inspection  of  the  source  code  could  give  an 
indication  of  the  quality. 

In  addition  to  quality,  the  source  code  (if  obtained)  should  be  inspected  for  several 
characteristics.  The  source  code  should  be  easily  maintainable  since  properly  maintained 
software  enhances  the  secure  operation  of  that  software.  For  purposes  of  und^standing  the 
code,  the  code  should  be  modular  and  well  structured. 
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The  need  for  the  code  to  have  special  privileges  granted  by  the  operating  system  should  be 
kept  to  a  minimum  since  programs  executing  in  a  privileged  state  can  effectively  be  used  to 
exploit  vulnerabilities.  The  service  should  only  provide  features  that  are  related  to  that 
service  to  keep  the  code  concise  and  understandable  thereby  reducing  the  risk  of  introducing 
security  flaws.  There  should  be  no  "back  doors"  in  the  code,  such  as  master  passwords  and 
undocumented  commands  used  for  debugging  purposes,  since  these  back  doors  result  in 
improper  monitoring  and  access  control  of  the  user. 


24 


General  Assurance  Techniques 
(Concluded) 


•  Verify  service  operates  as  Intended 

-  ln>house  penetration  testing 

-  Documentation 

-  Conformance  certification 

e  Host  service  on  OS  with  security  features 
equivalent  to  C2  functionality  or  better 

-  Discretionary  access  control  (DAC) 

-  Object  reuse 

-  User  Identification  and  authentication 

-  Process  isolation 

e  Appropriate  system  and  service  administration 


Another  important  assurance  technique,  and  one  that  is  critical  in  the  absence  of  a  formal 
evaluation  or  source  code,  is  to  verify  that  the  service  operates  as  intended.  In-house, 
informal  penetration  testing  can  be  done  to  perform  this  verification.  It  is  important  to  note, 
however,  that,  without  source  code,  penetration  testing  may  not  find  all  vulnmbilities. 

Adequate  documentation  describing  the  operation  of  the  service  should  be  supplied  be  die 
vendor  to  aid  in  the  verification  process.  This  documentation  is  essential  when  source  code 
is  not  available  so  that  penetration  testing  can  be  effective.  Formal  conformance  cotification 
would  also  show  that  the  service  operates  as  intended. 

Hosting  the  service  on  an  operating  system  (OS)  with  security  features  equivalent  to  C2 
functionality  or  above  is  another  usefU  assurance  technique.  The  C2  criteria  and  others  are 
described  in  the  Trusted  Computer  System  Evaluation  Criteria  (TCSEC)  published  by  NSA. 
The  functionality  within  die  C2  criteria  include  discretionary  access  control  (DAC),  object 
reuse,  user  identification  and  authentication,  and  process  isolation.  These  are  defined  briefly 
as  foUows: 

1 .  DAC  involves  read,  write,  and  execute  penrassions  granted  to  an  individual,  a  group, 
and  the  public. 


2.  Object  reuse  guarantees  that  no  information  produced  by  a  prior  user  is  to  be  made 
available  to  another  user  that  obtains  access  to  an  object  that  was  released  back  to  the 
system.  For  ^  ♦ance,  when  a  user  deletes  a  file,  another  user  should  not  see 
information  the  deleted  file  when  the  disk  space  is  reallocated. 

3.  identification  and  authentication  requires  that  users  must  identify  themselves  to 
the  OS,  and  that  the  OS  must  authenticate  the  users  before  any  actions  are  performed 
on  behalf  of  the  users. 

4.  Process  isolation  requires  that  resources  within  the  system  be  isolatable  so  that  access 
control  mechanisms  can  be  used  to  protect  them. 

Once  installed,  the  continued  correct  operation  of  die  service  should  be  ensured  through 
careful  administration  of  both  the  service  and  the  system  hosting  the  service.  Included  in  this 
administration  is  the  establishing  and  monitoring  of  configuration  information  relating  to  the 
host  and  to  the  service.  'Iliis  countermeasure  is  critical  for  boundary  host  systems  since  they 
are  part  of  MTTRE's  security  boundary. 
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Specific  Threats  and  Vuinerabiiities: 
Modification 


•  Threats 

-  Modification  of  messages 

-  Destruction  of  messages 

-  Corruption  of  routing 
Information 

e  Vulnerability 

-  Stored  information 


Threats,  vulnerabilities,  and  countermeasures  specific  to  X.400  will  now  be  identified. 

One  threat  within  the  MHS  environment  is  the  threat  of  unauthorized  modification.  As 
messages  travel  through  the  MHS,  there  is  the  potential  that  diey  could  be  modified  or 
destroyed. 

In  addition  to  messages  being  modified,  routing  information  could  be  corrupted.  Routing 
information  is  the  information  required  to  get  the  message  from  the  originator  to  its 
destination.  X.S00  is  responsible  for  maintaining  this  infonnadon.  However,  if  X.S00  is  not 
in  place,  the  information  can  be  stored  statically  for  use  by  X.400. 


The  method  in  which  information  is  stored  is  one  vulnerability  that,  if  exploited,  could  lead 
to  unaudiorized  modification.  This  vulnerability  is  discussed  on  the  following  slide. 


Specific  Vulnerabilities  and  Countermeasures: 
Stored  Information 


•  Description 

-  Saved  messages 

-  Messages  deferred  for  delivery 

-  Messages  fwld  for  delivery 

-  Queued  messages 

-  Routing  information 
e  Vulnerability 

-  Stored  information  may  not  be  adequately  protected 

-  Users  may  gain  unauthorized  access 
e  Countermeasure 

•  Operating  system  capable  of  DAC 

-  Stored  Information  is  an  OS  ot^ect  owned  by  appropriate 
user 


There  are  various  types  of  stored  messages  within  an  MHS.  These  stored  messages  include 
the  following: 

1.  Messages  that  users  save  in  a  message  store, 

2.  Messages  that  the  MTS  is  deferring  delivery  of  to  remote  users  until  a  certain  time 
specified  by  the  originator, 

3.  Messages  that  users  have  requested  the  MTS  to  hold  for  delivery  to  them  until  they 
ate  available  to  process  the  messages,  and 

4.  Messages  that  ate  queued  for  delivery  within  the  MTS. 

If  these  stored  messages  are  not  protected  adequately,  users  could  modify  them  without 
proper  authorization. 

In  addition  to  stored  messages,  routing  and  management  information  may  also  be  stored. 
Again,  if  not  adequately  protected,  this  information  could  be  modified  without  authorization. 
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To  protect  internally  stored  information,  the  operating  system  where  the  information  is 
located  must  be  capable  of  performing  discretionary  access  control.  Also,  the  information 
must  be  recognized  as  an  object  by  the  OS  so  that  the  OS  can  use  the  DAC  mechanisms  to 
protect  the  information.  Each  message  must  be  associated  with  the  appropriate  owner.  Saved 
messages  should  be  owned  by  the  recipient  Ml^-user.  Deferred  messages  should  be  owned 
by  the  originating  MTS-user.  Held  messages  and  queued  messages  should  be  owned  by  the 
MHS  administrator. 

A  group  of  messages  can  be  contained  in  one  OS  object  if  all  messages  are  owned  by  one 
user.  However,  multiple  messages  owned  by  several  users  cannot  be  contained  in  one  OS 
object  since  operating  systems  usually  perform  DAC  at  the  object  level. 

MITRE  cannot  provide  for  the  protection  of  ext^ally  stored  information.  Information 
received  from  external  sources  cannot  be  guaranteed  to  have  not  been  modified,  and  the 
prevention  of  the  modification  of  information  sent  externally  cannot  be  ensured. 
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Specific  Threats  and  Vuinerabiiities: 
Disciosure 


•  Ttiraats 

-  Loss  of  confMsmiallty 
*■  Loss  of  privacy 

-  Misappropriation  of  msssagss 

-  Traffic  analysis 
a  Vulnerabllitiss 

-  Msssags  storage 

•  As  described  previously 

-  Distribution  lists 

-  Altemate  recipient  allowed  argument 

-  Recipient  reassignmem  allowed  argument 

-  Replies  to  messages  with  blind  copy  recipients 


As  with  unauthorized  modification,  diere  are  also  various  farms  of  unauthorized  disclosure. 
Loss  of  confidentiality  occurs  when  the  content  of  a  message  is  crqrtured  and  read  by  users 
for  whom  the  message  was  not  intended.  By  reading  message  header  information  ^t  may 
not  be  protected,  an  MTS-user  can  detect  who  authored  a  particular  message  which  would 
result  in  loss  of  privacy  concerning  authorship.  Misappropriation  occurs  when  messages  are 
delivered  to  the  wrong  MTS-user,  either  through  misuse  or  errors.  Also,  message  traffic  can 
be  aiuilyzed  to  ascertain  information.  (Pizza  shops  in  the  Pentagon  area  know  important 
events  are  transpiring  when  the  number  of  requests  for  delivery  take  a  sharp  increase.) 

Thoe  are  a  number  of  vulnerabilities  relating  to  unauthorized  disclosure.  As  described 
previously,  unauthorized  access  can  be  gained  to  stored  messages  to  either  read  or  modify  the 
messages.  Distribution  lists  can  also  result  in  unauthorized  disclosure.  Two  arguments 
supplied  during  a  message  submission  operation,  altemate  recipient  allowed  and  recipient 
reassignment  tUlowed,  can  result  in  a  message  being  sent  to  a  recipirat  without  the 
knowledge  of  the  originator.  Finally,  the  manna*  in  which  replies  are  sent  to  messages  that 
have  blind  copy  recipients  can  result  in  unaudiorized  disclosure. 

More  detail  on  each  of  diese  vulnoabilities  is  given  in  the  following  slides. 
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Specific  Vuinerabiiities  and  Countermeasures: 
Distribution  Lists 


•  Description 

-  A  group  Hst  containing  directory  names  and  possibly 
ottm  aistrtt)ution  lists 

e  Vulnerability 

-  Originator  may  be  misinfonned  about  membership 

-  Nesting  of  distribution  lists  adds  to  the  problem 
e  Countermeasure 

-  Automate  X.S00  list  request  (hiring  message  siAmIsslon 
operation 

•  May  require  code  mrxllflcation 

-  Instruct  users  to  perform  X.S00  list  requestor  DL 
expansion  prohibited  during  message  siAmbslon 
operation 


Distribution  lists  (DL),  provided  through  X.500,  are  used  to  identify  a  group  of  people  that 
have  common  interests  so  that  messages  can  be  easily  soit  to  all  individuals  interested  in  a 
particular  topic.  A  distribution  list  contains  directory  names  and  possibly  other  distribution 
lists. 

Since  distribution  lists  may  undergo  many  changes  and  may  be  lengthy,  the  originator  of  a 
message  using  a  distribution  list  may  be  misinformed  as  to  the  actual  list  membership. 
Nesting  of  distribution  lists  (a  list  within  a  list)  adds  to  the  confusion.  If  the  originator  is 
misinformed  about  the  list  membership,  a  message  could  be  sent  to  unintended  recipients. 

One  countermeasure  to  this  problem  would  be  to  have  DL  membership  automatically 
reported  to  the  originator  before  the  message  is  sent  through  the  list  request  optraAon. 
However,  in  addition  to  requiring  modification  of  OSI  code,  expanding  the  distribution  list 
could  be  cumbersome  for  the  user.  As  stated  previously,  distribution  lists  can  be  lengthy, 
and,  when  the  message  content  is  not  sensitive  in  the  originator's  opinion,  the  originator  may 
not  want  to  see  every  name  on  the  distribution  list 
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Another  countermeasure  is  to  simply  instract  the  originator  to  expand  the  list  through  a  list 
request  or  prevent  the  delivery  of  messages  that  unknowingly  contain  a  distribution  list 
recipient  with  the  distribution  list  expansion  prohibited  argument. 

Ml'l'kE  cannot  instruct  external  originators  to  perform  this  countermeasure.  Therefore, 
inbound  mail  received  from  an  external  source  could  be  delivered  to  recipients  within  MITRE 
without  the  knowledge  of  that  external  source.  However,  this  does  not  pose  a  security  threat 
to  MITRE  data. 
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Specific  Vuinerabiiities  and  Countermeasures: 
Aiternate  Recipient  Aiiowed 


•  Description 

-  Resuits  in  deiivery  of  message  to  altemate  if  primary 
cannot  be  determined 

e  Vuinerabiilty 

-  Originator  does  not  have  controi  over  who  actualiy 
receives  message 

e  Countermeasure 

-  Do  not  make  a/femate  nciplent  allowed  uniaWabio 

-  Have  user  specify  altemate  recipient  prohibitad 

-  Default  is  altemate  recipient  pmhibited 


The  altemate  recipient  feature  allows  a  destination  MTA  to  deliver  a  message  to  an  altemate 
recipient  designated  by  that  MTA  if  die  primary  recipient  cannot  be  determined  from  the 
information  provided  by  the  originator.  For  this  feature  to  work,  the  alternate  recipient 
allowed  axgament  would  have  to  be  specified  by  the  originator  during  message  submission, 
and  the  destination  MTA  would  have  to  have  an  altemate  recipient  designated.  The  problem 
with  this  feature  is  that  the  originator  does  not  know  who  the  altemate  recipient  is,  and  die 
originator  may  not  want  the  altemate  recipient  to  receive  the  information. 

One  possible  countermeasure  is  to  not  allow  the  originator  to  supply  the  altemate  recipient 
allowed  aigament  by  having  the  originating  MTA  automatically  override  this  argument  with 
the  alternate  recipient  ptoMbitedzxgamstA.  fr  automation  is  not  possible  or  desired  (since  at 
times  it  is  beneficial  to  have  an  altemate  recipient  for  critical  messages),  users  could  be  asked 
to  set  the  altemate  recipient  prohibited  argument  during  message  submission.  The  default 
specified  in  the  recommendation  is  to  prohibit  an  altemate  recipient 

MITRE  cannot  instruct  external  originators  to  perform  this  countermeasure.  Therefore, 
inbound  mail  received  from  an  external  source  could  be  delivered  to  an  altemate  recipient 
within  MITRE  without  the  knowledge  of  that  external  source.  However,  diis  does  not  pose  a 
security  threat  to  MITRE  data. 
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specific  Vulnerabilities  and  Countermeasures: 
Recipient  Reassignment  Allowed 


•  DMcrlption 

-  Enabtes  users  to  Instruct  the  MTS  to  rediract  incoming 
messages  addressed  to  them 

a  Vulnerability 

-  Originator  does  not  know  who  the  recipient  is  or  even 
ttai  the  message  has  been  redirected 

-  Mended  recipient  doesn't  ever  receive  message 
e  Countermeasure 

-  Do  not  make  nciplent  nasslgntimnt  aMowvd  available 

-  Have  user  specify /ec#>leitfrsasa/0n«iMnfp/DhJbiled 

-  Change  default  which  is  nelpl^nt  naaaigmwnt  allowed 


The  recipient  leassignment  feature  allows  users  to  instruct  the  MTS  to  redirect  incoming 
messages  addressed  to  them.  The  intended  recipient  specifies  to  whom  the  messages  are  to 
be  redirected,  without  the  knowledge  or  iqrproval  of  the  originator.  With  this  feature,  the 
intended  recipient  never  receives  the  message.  For  this  feature  to  work,  the  recipient 
reassignment  allowed  dxgasneat  would  have  to  be  ^)ecified  by  the  originator  during  message 
submission,  and  the  intended  lecipioit  would  have  to  have  an  alternate  rec^ient  designated. 

As  with  the  alternate  recipient  feature,  one  possible  countermeasure  is  to  not  aUow  the 
originator  to  supply  the  reorient  reassignment  allowed  argument  by  having  the  originating 
MTA  automatically  override  this  argumoit  with  die  reorient  reassignment  prohibited 
argument  If  automation  is  not  possible  or  desired,  users  could  be  asked  to  set  die  redpieru 
reassignment prohibitedargameat  during  message  submission.  The  default  specified  in  the 
recommendadon  is  to  allow  recipient  reassignment  This  default  should  be  changed  so  diat 
this  feature  is  not  invoked  without  the  originator  specifically  allowing  it 

MITRE  cannot  instruct  external  originators  to  perform  this  countermeasure.  Therefore, 
inbound  mail  received  from  an  external  source  could  be  redirected  within  MITRE  without 
the  knowledge  of  that  external  source.  However,  this  does  not  pose  a  security  threat  to 
MITRE  data. 
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Specific  Vuinerabiiities  and  Countermeasures: 
Repiies  to  Biind  Carbon  Copy  Recipients 


•  Description 

-  BCC  iist  aiiows  originator  to  keep  some  recipients  hidden 
from  others 

e  Vuinerabiiity 

-  Biind  copy  recipients  are  not  disciosed  to  repiier 

-  Repiier  may  not  know  where  the  message  is  going 
e  Countermeasure 

-  Biind  cartwn  copy  recipients  shouid  be  removed  from 
recipient  iist  at  destination  MTA 


The  blind  carbon  copy  (BCC)  feature  allows  a  user  to  specify  recipients  of  a  message  that 
direct  recipients  and  carbon  copy  recipients  of  the  message  do  not  see.  The  concern  with  this 
feature  involves  replies  to  messages  that  have  BCC  recipients.  A  user  can  globally  reply  to  a 
message  and  have  the  reply  automatically  sent  to  the  originator  and  aU  recipients  of  the 
message.  The  recommendation  does  not  state  that  BCC  recipients  should  not  receive  any 
replies  to  a  message.  Therefore,  depending  on  the  implementation,  a  reply  could  be  sent  to 
someone  without  the  knowledge  of  the  repiier. 

The  countermeasure  to  this  problem  is  to  verify  that  the  implementation  removes  the  BCC 
list  at  each  destination  MTA. 

MITRE  cannot  instruct  external  MTAs  to  perform  this  countermeasure.  Therefore,  blind 
carbon  copy  recipients  within  MITRE  may  receive  replies  to  messages  without  the 
knowledge  of  the  external  repiier.  However,  this  does  not  pose  a  security  threat  to  MITRE 
data. 
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Specific  Threats  and  Vuinerabiiities: 
Deniai  of  Service 


•  Threats 

-  Deniai  of  communications 

-  MS  failure 

-  MTA  failure 

-  MTS  flooding 

•  Vulnerability 

-  Pifonty  argurnem 


Denial  of  service  could  be  achieved  through  a  breakdown  in  the  network,  the  failure  of  an 
MS  or  MTA,  or  the  flooding  of  the  MTS  with  messages.  Any  of  these  problems  results  in 
the  inability  to  deliver  messages. 

One  vulnerability  that  can  be  exploited  to  cause  a  denial  of  service  concerns  the  user's  ability 
to  specify  the  priority  of  a  message.  This  is  discussed  on  the  following  slide. 


36 


Specific  Vuinerabiiities  and  Countermeasures: 
Priority  Argument 


•  Description 

-  User  requests  urgent,  normai,  or  nonurgent 

-  Different  from  importance  indication 
e  Vuinerabiiity 

->  Modifies  time  periods 
e  Countermeasure 

-  Do  not  allow  users  this  privilege 

-  Establish  threshold 


Denial  of  service  can  be  achieved  through  users  flooding  the  MTS  with  messages.  The 
ability  of  users  to  specify  the  priority  of  their  messages  increases  the  rate  at  which  flooding 
could  occur. 

The  priority  of  a  message  can  be  either  urgent,  normal,  or  nonurgent  This  is  different  from 
an  in^rtance  indication  which  informs  the  recipient  whether  or  not  die  originator  considers 
the  message  an  important  one  that  should  be  read  as  soon  as  possible.  In  terms  of  the  qualiQr 
of  sovice  that  the  MTS  must  provide,  an  urgent  message  has  a  shorter  period  of  time  in 
which  it  must  be  processed  by  die  MTS  than  a  nonnal  or  nonurgent  message.  Thoefore,  an 
urgent  message  may  be  processed  more  quiddy  than  a  normal  or  nonurgent  message. 

Since  the  MTS  may  process  urgent  messages  more  quickly  than  other  messages,  a  user  could 
flood  the  MTS  with  urgent  messages  and  delay  the  processing  of  normal  or  nonurgent 
messages. 
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As  a  countenneasure  to  this  problem,  the  privilege  to  set  the  priority  on  a  message  should 
only  be  granted  to  a  system  administrator  or  MHS  administrator.  A  standard  MHS-user 
should  not  be  granted  this  privilege.  To  prevent  external  MHS-users  or  MTAs  from 
flooding  MITRE'S  internal  MHS  with  urgent  messages,  a  threshold  on  the  number  of  urgent 
messages  processed  could  be  established.  Once  this  threshold  was  reached,  the  boundary 
MTA  could  reset  the  priority  of  the  messages  to  normal. 
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Specific  Threats  and  Vuinerabiiities: 
Masquerade 


I 

I 

I 

I 

I 

I 

I 


•  Threats 

-  Impersonation  of  an  MTS-user  to  an  MTA 

-  Impersonation  of  an  MTA  to  an  MTS*user 

-  Impp  eonatlon  of  an  MTA  to  another  MTA 

-  Imp  sonation  of  an  MS  to  a  UA 

-  Impersonation  of  a  UAto  an  MS 

•  Vulnerabilities 

-  0/R  name  argument 

-  Credentials  argument 
>  Register  operation 


There  are  five  fonns  of  masquerade  that  could  take  place:  impersonation  of  an  MTS>user  to 
an  MTA,  impersonation  of  an  MTA  to  an  MTS-user,  impersonation  of  an  MTA  to  another 
MTA,  impersonation  of  an  MS  to  a  UA,  and  impersonation  of  a  UA  to  an  MS. 

There  are  three  specific  vulnerabilities  that  pose  a  threat  of  masquerade.  These 
vulnerabilities  relate  to  die  originatorAecipient  (O/R)  name  supplied  witfi  many  operations, 
the  credentials  given  during  a  bind,  and  the  register  operation.  These  are  discussed  in  more 
detail  on  the  following  slides. 
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Specific  Vuinerabiiities  and  Countermeasures: 

0/R  Name 


»  DMcrlpUon 

-  CoiMalfis  0/R  address  and/or  directory  name 

-  If  both  are  present 

•  0/R  address  Is  used 

•  Directory  name  Is  Ignored  but  passed  on  to  receiver 
a  Vulnerability 

-  Sender  Is  able  to  supply  false  directory  name 

-  Receiver  Is  more  IHcely  to  consult  directory  name 
a  Countermeasure 

-  Have  originating  and  destination  MTA  resolve  directory 
name 


An  O/R  name  conqrrises  a  diiectory  name,  an  0/R  address,  or  both.  A  directory  name  is 
intended  to  be  a  user-firiendly  name  that  can  be  easily  associated  with  a  particular  user.  The 
directory  name  can  be  used  to  determine  an  O/R  address  by  performing  a  look-up  in  the 
X.S00  directory.  An  O/R  address  contains  information  that  enables  the  MHS  to  uniquely 
identify  users  and  to  route  messages  or  return  notifications  to  than. 

When  both  an  O/R  address  and  a  directory  luune  are  given  as  part  of  an  O/R  name,  the  MHS 
will  use  the  O/R  address  but  will  carry  the  directory  name  and  present  both  to  the  recipient 
This  presents  the  opportunity  for  the  sender  to  siqrply  a  false  directory  luime  with  die 
intention  of  deceiving  the  receiver  as  to  who  actually  sent  die  message.  When  the  message  is 
delivered  to  the  receiver,  die  receiver  is  more  likely  to  consult  the  user-firiendly  directory 
name  than  the  O/R  address.  The  receiver  could  then  respond  to  the  message  thinking  that  the 
response  is  going  to  the  user  associated  with  the  directory  name  rather  than  the  user 
associated  with  the  O/R  address. 

The  countermeasure  to  this  vulnerability  is  to  have  the  destination  MTA  and,  for  added 
security,  the  originating  MTA  resolve  the  directory  name  and  conqiare  the  result  with  the 
O/R  a^ess.  If  the  O/R  address  did  not  match  the  directory  name,  the  message  should  be 
discarded  or  tiie  directory  name  should  be  changed  to  match  the  O/R  address. 
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This  countermeasure  is  not  currently  possible,  however,  when  messages  are  generated 
externally.  MITRE  does  not  cunently  have  a  method  to  verify  O/R  addresses  and  direaory 
names  that  are  external  to  MITRE.  Eventually,  distributed  directory  services  will  be  more 
mature,  and  MITRE  will  be  able  to  perform  this  countermeasure  for  externally  generated 
messages.  Until  that  time,  users  within  MITRE  should  take  care  with  any  information  that 
is  received  from  outside  of  the  company. 
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Specific  Vuinerabiiities  and  Countermeasures: 

Credentiais 


•  Ooscrlptlon 

-  Contain  password  or  token 

>  Prasenca  is  reqtilrad,  but  authentication  is  not 
a  VuinerabilKy 

-  Sander  can  supply  any  0/R  nanw 

-  Racalvar  must  beilava  supplied  0/R  name 
a  Countermeamire 

-  Perform  local  authentication 


When  binding  to  the  MTS,  cxedoitials  must  be  supplied  by  die  initiator.  If  simple 
authentication  is  used,  the  credentials  contain  a  password.  If  strong  authentication  is  used, 
the  credentials  contain  a  token  and,  optionally,  a  certificate. 

Although  the  credentials  must  be  supplied  by  the  initiator,  the  responder  is  not  required  to 
perform  any  authentication  using  diese  credentials.  If  no  authentication  is  performed,  the 
initiator  can  supply  any  credentials. 

A  countermeasure  to  false  credentials  is  to  have  a  valid  audientication  scheme  resident  on  all 
MTAs  within  MITRE. 

MITRE  cannot  instruct  external  MTAs  to  poform  this  countermeasure.  Thoefore,  a  MITRE 
user  may  be  able  to  gain  access  to  an  external  MHS  by  providing  false  credoitials.  However, 
this  does  not  pose  a  security  threat  to  MITRE  data. 
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Specific  Vuinerabiiities  and  Countermeasures: 

Register 


•  Description 

-  Option  enables  a  user  to  make  changes  to 
paniiiieters  held  by  the  MTS 

•  Username 

•  User  address 

•  Vulnerability 

-  User  can  supply  any  name  or  address 
e  Countermeasure 

-  Control  and  restrict  access  to  this  command 


The  register  operation  allows  an  MTS-user  to  make  long-term  changes  to  various  parameters 
of  the  MTS-user  held  by  the  MTS  concerned  widi  delivery  of  messages  to  the  M13-user. 
Two  of  these  parameters  are  the  user  name  and  the  user  address.  The  user  name  is  the  0/R 
name,  and  the  user  address  is  either  the  X.121  address,  the  transport  service  access  point 
(TSAP)  identifier,  or  the  presentation  service  access  point  (PSAP)  address.  The 
recommendation  does  not  specify  any  restrictions  concerning  the  use  of  this  operation, 
therrfore,  an  MTS-user  can  supply  any  name  and  any  address.  Dep«iding  on  how  die  MTS 
uses  this  information,  other  MTS-users  or  the  MTS  itself  could  be  deceived  as  to  who  the 
actual  user  is.  Access  to  this  command  needs  to  be  restricted  to  system  or  mail 
administrators.  Alternatively,  users  can  be  allowed  restricted  write  access  to  their  own  entry. 
Under  this  restricted  access,  users  can  modify  only  those  attributes  that  have  been  designated 
as  bong  changeable  by  standard  users. 

MITRE  cannot  instruct  external  MTAs  to  perform  this  countermeasure.  Therefore,  MITRE 
users  may  be  able  to  change  their  register  information  held  by  an  external  MTS.  However, 
this  does  not  pose  a  security  threat  to  MITRE  data. 


43 


Specific  Threats  and  Vuinerabiiities: 
Resequencing 


•  Threats 

-  Replay  of  messages 

-  Reordering  of  messages 

-  Praplay  of  messages 

-  Delay  of  messages 
e  VulnerBbttIty 

-  Cmc^DeMTBd  Delivery  open/Oon 


In  tenns  of  resequencing,  messages  can  be  replayed,  reordered,  preplayed,  or  delayed.  Any 
of  these  resequendngs  could  cause  confusion  or  result  in  information  arriving  too  late  or  too 
early. 

As  described  on  the  next  slide,  cancelling  a  deferred  delivery  could  cause  prq>lay  of 
messages. 
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Specific  Vuinerabiiities  and  Countermeasures: 
Cancel  Deferred  Delivery  Operation 


•  Description 

-  Requires  only  message  siOtmlsslon  identifier  as  an 
argument 


e  Vulnerability 

-  One  user  can  cancel  someone  eise's  deferral 

-  Receiver  will  get  message  before  originator  intended 


e  Countermeasure 

-  Auttienticate  user  as  originator 


The  deferred  delivery  feature  allows  an  originator  to  submit  a  message  to  an  MTS  but  request 
that  the  MTS  not  deliver  the  message  to  the  intended  recipient  until  a  specific  time.  As  a 
complement  to  this  feature,  the  cancel  deferred  delivery  operation  allows  a  user  to  cancel  the 
delay  time  associated  with  the  delivery  of  a  deferred  message  and  have  the  message 
delivered  immediately.  However,  the  only  argument  that  a  user  must  supply  to  perform  a 
cancellation  is  a  message  submission  identifier.  Therefore,  one  user  could  supply  any 
message  sulmiission  identifier  and  cancel  another  user's  deferral  resulting  in  the  delivery  of  a 
message  earlier  than  intended  by  the  originator. 

As  a  countenneasure  to  this  vulnerability,  the  MTS  should  authenticate  that  the  user 
performing  the  cancellation  of  the  deferred  delivery  time  is  the  originator  of  the  deferred 
message. 

MITRE  cannot  instruct  external  MTAs  to  perform  this  countermeasure.  Therefore,  a  MITRE 
user  could  gain  access  to  an  external  MHS  and  cancel  the  deferred  delivery  of  an  external 
user.  However,  this  does  not  pose  a  security  threat  to  MITRE  data. 
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Specific  Threats  and  Vuinerabiiities: 
Repudiation 


•  Threats 

-  Ssnial  of  origin 

-  Denial  of  submission 

-  Denial  of  delivery 
e  Vulnerability 

-  Messages  held  for  delivery 


repudiation  could  take  three  forms  within  an  MHS.  The  audior  could  deny  having 
originated  the  message  (denial  of  origin),  the  MTS  could  deny  having  received  the  message 
from  the  originator  (deiual  of  submission),  and  the  recipient  could  deny  having  received  the 
message  from  the  MTS  (denial  of  delivery). 

The  method  in  which  messages  that  are  held  for  delivery  are  protected  could  result  in  a  user 
being  able  to  deny  having  been  delivered  a  message.  This  vulnerability  is  described  on  the 
following  slide. 
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Specific  Vuinerabiiities  and  Countermeasures: 
Hoid  for  Deiivery 


•  Doscription 

-  Messages  are  held  !n  temporary  storage  until  requested 
for  deiivery 

e  Vulnerabliity 

-  Receiver  may  be  able  to  read  temporary  storage  while 
repudiating  receipt 

e  Countermeasure 

*  Do  not  allow  temporary  storage  to  be  readable  by 
receiver 


Along  with  unauthorized  disclosure  and  modification,  messages  that  the  MTS  is  holding  for 
delivery  can  result  in  false  repudiation  of  receipt  If  the  temporary  storage  where  the 
messages  are  located  is  not  adequately  protected,  usos  can  gain  access  to  the  storage,  read 
the  messages  that  are  being  held  for  them,  and  then  repudiate  having  received  them  since  the 
messages  were  never  actually  delivered  to  the  users. 

The  countermeasure  to  this  repudiation  problem  is  to  provide  proper  discretionary  access 
control  on  the  temporary  storage,  as  should  be  done  with  the  disclosure  and  modification 
threat  These  held  messages  should  be  owned  by  the  system  or  mail  administrator  and 
should  be  readable  by  only  these  administrators. 
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Assurance  Techniques: 
Essential  (E)  or  Desired  (D) 


•  The  tallowing  sssurance  techniques  are  desirable,  but  not 
essential,  since  penetration  testing  can  be  used  to  verify 
Implenientatlon 

-  Evaluated  or  assessed  product:  D 

-  Acquisition  of  source  code:  D 

~  Source  code  that  is  modular  and  concise:  D 

-  Source  code  that  Is  easily  maintainable:  D 

-  Enforcement  of  least  privilege:  D 

-  Absence  of  extraneous  features:  D 
e  Absence  of  *lMck  doors"  E 

-  If  source  code  Is  available,  a  determination  should  be 
made  that  no  back  doors  exist 


That  concludes  die  discussion  of  idendfled  threats,  vulnerabilities,  and  countermeasures 
specific  to  X.400.  Those  threats,  vulnerabilities,  and  countermeasures  identified  are  intended 
to  be  inclusive  given  the  scope  of  the  analysis.  However,  additional  issues  may  be  idoitified 
as  penetration  testing  and  evaluations  of  specific  implementations  proceed. 

The  general  assurance  techniques  and  specific  countermeasures  will  now  be  examined  in 
terms  of  whedier  they  are  essential  to  any  implonentation  integrated  into  MTTRE  networks  or 
whether  they  are  de^red,  but  not  essential,  llie  criticality  of  each  wiU  be  discussed  in  the 
order  that  they  were  previously  discussed.  These  next  several  slides  are  summarized  towards 
the  end  of  die  briefing. 

Many  of  the  general  assurance  techniques  work  in  concot  to  ensure  that  the  service  operates 
as  intended.  The  primary  assurance  technique  that  ensures  this  is  penetration  testing. 
Therefore,  general  assurance  techniques,  such  as  the  use  of  evaluated  or  assessed  products, 
the  iKxiuisition  of  source  code,  modular  and  concise  source  code,  maintainable  source  code, 
the  enforcenwnt  of  least  privilege,  and  the  absence  of  extraneous  features,  are  all  desirable 
assurance  techniques,  but  are  not  essential. 

The  absence  of  bturk  doors  into  die  service  is  essential  to  ensure  correct  operation  of  the 
service.  If  source  code  is  available,  the  code  must  be  inspected  for  these  back  doOTs,  and  die 
b«dc  doors  must  be  removed,  if  present 
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Assurance  Techniques: 
Essential  (E)  or  Desired  (D)  (Concluded) 


•  Penetration  testing:  E 

-  Without  source  code,  only  method  of  determining  If 
Implementation  operates  as  Intended 

e  Documentation:  E 

-  Aids  In  penetration  testing 
e  Conformance  certHIcatlo.i:  D 

-  Conformance  can  be  indicated  through  penetration 
testing 

e  OS  security:  E 

-  To  protect  the  operation  of  the  service,  the  OS  must 
provide  C2  functionality 

e  System  and  service  administration:  E 


Penetration  testing,  as  implied  earlier,  is  essential  to  verifying  that  the  service  operates  as 
intended.  Without  source  code,  penetration  testing  is  die  only  method  of  making  this 
determination. 

As  an  aid  to  effective  penetration  testing,  documentation  is  also  essential. 

Conformance  certification,  though  desirable,  may  not  be  practical  to  require.  Penetration 
testing  can  provide  an  indication  as  to  how  well  the  implementation  conforms  to  the 
recommendation. 

To  protect  the  proper  operation  of  the  service,  OS  security  is  essential.  At  a  minimum,  the 
functionality  specified  within  the  C2  requirements  of  the  TCSEC  must  be  provided  by  the 
OS. 

To  guarantee  the  continued  correct  operation  of  the  service,  both  die  service  and  the  system 
hosting  the  service  must  be  carefully  administered.  This  includes  correcdy  establishing  and 
pCTiodically  inspecting  the  configuration  of  the  host  and  the  service. 
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Countermeasures : 
Essential  (E)  or  Desired  (D) 


•  Protoction  of  storad  information:  E 

-  Storage  must  be  protected  adecpiateiy 

e  Automated  expansion  of  distribution  lists:  D 

-  User  can  take  manual  action  to  expand  DLs 

e  Automatic  prohibiting  of  alternates  and  reassignments:  D 

-  User  can  take  manual  action  to  prohibit 

e  Removal  of  blind  copy  recipients  before  replies:  E 

-  BCC  recipients  must  be  removed 

e  Access  comrol  for  assignrnem  of  message  priority:  D 

-  User  can  flood  the  MTS  m*  MTA  using  other  methods 


The  protection  of  stored  information  is  an  essential  countermeasure  to  prevent  unauthorized 
modification  and  unauthorized  disclosure. 

Some  countermeasures  need  not  be  automated  since  the  user  can  lake  a  manual  action  to 
provide  the  countermeasure.  For  instance,  the  user  can  manually  «pand  distribution  lists, 
prohibit  alternate  recipients,  and  prohibit  recipient  reassignments. 

To  prevent  unauthorized  disclosure,  blind  carbon  copy  recipients  should  be  hidden  from 
other  recipients  in  every  respect  Therefore,  die  removal  of  the  BCC  list  as  soon  as  possible 
is  an  essential  countermeasure. 

Since  the  risk  of  flooding  the  MTS  or  MTA  with  high  priority  messages  is  not  much  greater 
than  die  risk  of  flooding  the  MTS  or  MTA  with  normal  priority  messages,  establishing 
access  controls  on  the  use  of  the  priority  argument  is  desirable,  but  not  essential. 
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Countermeasures : 

Essential  (E)  or  Desired  (D)  (Concluded) 


•  Rosolution  of  directory  name  wtth  O/R  address:  E 

-  Resolution  must  be  performed  automatically 
e  Authentication  of  credentials:  E 

-  Users  must  be  authenticated 

e  Access  control  for  register  operation:  E 

-  Access  to  register  Information  must  be  controlled 
e  Authentication  of  deferred  delivery  cancellation:  E 

-  Users  should  only  be  able  to  cancel  their  own  deferred 
delivery  times 

e  Protection  of  held  messages:  E 

-  To  prevent  repudiation,  held  messages  must  be  protected 
from  intended  recipient 


Other  essential  countermeasures  include  the  resolution  of  the  directory  name  with  the  0/R 
address  supplied  in  the  O/R  name,  the  authentication  of  credentials,  and  access  control  to  the 
register  operation.  These  countermeasures  are  critical  to  the  prevration  of  masquerading 
performed  to  achieve  unauthorized  disclosure  and  unauthorized  modiflcation. 

To  prevent  resequencing  problems,  the  cancellation  of  a  deferred  delivery  must  be 
authenticated. 

To  prevent  repudiation,  held  messages  must  be  protected  from  the  intended  recipient 
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Location  of 

X.400  Specific  Countermeasures 


1  Internal  Boundary  Internal  Internal 

CountwniMSura 

MTA 

MTA 

UA 

MS 

Stored  information  protection 

E 

E 

E 

E 

Distribution  list  expansion 

D 

No  alternate  recipient 

D 

No  recipient  reassignment 

D 

Removal  of  BCC  list 

E 

E 

Priority  access  comroi 

D 

D 

Resolution  of  0/R  name 

E 

E 

Authentication 

* 

* 

A 

* 

Register  access  comroi 

E 

E 

Authemicate  cancellation 

E 

E 

1  *  See  next  slide 

MITRE 

This  table  shows  the  MHS  conqwnent  on  which  each  countermeasure  is  implemented. 
MTAs  are  responsible  for  the  protection  of  stored  information,  ronoval  of  BCC  list, 
resolution  of  0/R  names,  authentication  of  credentials,  access  control  to  die  register 
operation,  access  control  in  the  setting  of  the  jniority  argument,  and  authentication  of 
deferred  delivery  cancellation. 

User  agents  are  responsible  for  protection  of  locaUy  stored  information,  distribution  list 
expansion,  prohibition  of  alternate  recipients,  and  prohibition  of  recipient  reassignment 

The  message  store  is  responsible  for  protection  of  locally  stored  information. 

The  responsibility  for  authentication  is  distributed  among  the  components,  and  the  type  of 
authentication  required  depends  upon  the  connection  being  made.  This  is  discussed  in  the 
next  slide. 
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Authentication  Requirements 


^Rospondw] 
InHI 


Internal 

UA 

Internal 

MS 

Internal 

MTA 

Boundary 

MTA 

External 

MTA 

External 

UA 


Internal 

UA 

Internal 

MS 

Internal 

MTA 

Boundary 

MTA 

External 

MTA 

- 

password 

password 

password 

- 

static 

password 

- 

static 

password 

static 

password 

- 

static 

password 

static 

pwBsword 

static 

password 

static 

password 

- 

static 

password 

static 

password 

static 

password 

static 

password 

static 

password 

- 

• 

- 

static 

password 

* 

• 

stronp 

- 

strong 

* 

/ 

This  table  shows  the  type  of  authentication  that  is  required  when  one  MHS  component 
connects  to  another.  Tte  dashes  represent  connections  that  cannot  be  made.  The  asterisks 
represent  connections  that  are  outside  the  scope  of  this  briefing. 

When  a  user  agmt  connects  to  an  MS  or  an  MTA,  password  authentication  is  required. 

When  an  MS  connects  to  a  UA,  MS,  or  MTA,  credentials  that  are  stored  on  the  components 
are  exchanged.  This  is  refened  to  as  a  static  password  exchange  since  the  credoitials  are 
stored  and  not  dynamically  entered  by  a  user. 

When  an  MTA,  internal  or  boundary,  connects  to  a  UA,  an  MS,  or  another  MTA,  static 
password  audientication  is  required. 

Whoi  an  external  MTA  connects  to  a  boundary  MTA,  static  password  authentication  is 
required. 

Currently,  an  external  user  agent  cannot  directly  connect  to  an  internal  MS  or  boundary 
MTA.  Hiere  is  a  requirement  to  be  able  to  access  mail  remotely,  however,  and  we  may  want 
to  enable  these  connections  in  the  future.  The  chart  dq>icts  that  if  these  connections  were  to 
be  allowed  they  would  require  strong  authentication. 
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This  chart  also  depicts  connections  that  may  not  be  permitted  at  MITRE.  In  particular, 
boundary  MTAs  will  probably  only  serve  as  relay  MTAs  with  no  end-users  being  served 
directly  by  the  boundary  MTA.  Therefore,  direct  connections  between  a  boundary  MTA  and 
an  internal  UA  or  internal  MS  may  not  be  allowed. 
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Summary  of  Assurance  Techniques 
and  Countermeasures 


Essential  -  General 

No  back  doors 
Ponotratlon  tasting 
Documantation 
OSaacurity 

Essential  -  Specific 
Protaetion  of  storad  infoimation 
Ramoval  of  BCC  radpiants 
Raaokition  of  0/R  nama 
Authantieation  of  ciadantiais 
Ragistar  accaaa  control 
Authentication  of  cancallation 

Mms 


Desired  -  General 
Evakiatad  products 
Source  coda 
Maintainability 
Modularity 
Least  privilaga 
No  axtranaoua  features 
Confonnanoa  certification 

Desired- Specific 
Expansion  of  distrftiutton  lists 
No  racipiant  altamata 
No  racipiant  raaasignnwnt 
Access  control  of  priority 


This  chart  simply  presents  a  breakdown  of  the  assurance  techniques  and  countermeasures 
according  to  whether  diey  are  essential  or  desired  and  general  or  ^)ecific. 
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Summary 


•  Many  of  tiM  Uentifiod  vuinMabilltles  axiat  within  current 
meaaaglng 

e  individual  imptamentations  may  remove  aome  vulnerabilities 

e  An  implementation  that  provides  essemialcountenneasures 
results  In 

-  An  acceptable  level  of  risk 

-  A  level  of  risk  that  is  less  than  the  level  of  risk  present 
with  current  messaging 


Now  that  these  vulnerabilities  have  been  de^riibed,  it  is  important  to  note  that  many  of  these 
vulnerabilities  exist  widiin  our  current  method  of  messaging.  Also,  individual 
implementations  may  address  and  remove  many  of  these  vulnerabilities.  Therefore,  an 
implementation  that  provides  all  essential  countermeasures  not  only  results  in  an  acceptable 
level  of  risk  when  integrating  it  into  the  MITRE  netwcnk,  but  also  results  in  a  level  of  risk 
that  is  less  than  the  level  of  risk  present  widi  current  messaging. 
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Recommendation 


•  Obtain  commereiaay  avallabte  Implamantallons  of  X.400 

•  HawMt  Packard 

-  PP  (ISOOE  Consortium) 

-  DEC 

•  Analyze  sach  implemeidation  to  detennina  which 
cournanneasuras  are  met 

a  Integrate  ImptoriMntidion  baaed  on 

-  Countermeasures 

-  Functionality 

-  Security  services 

e  For  enabled  services,  Implementation  must  provide  essential 
countermeasures 


For  the  MITRE  OSI  Integration  Project,  die  rBcommaidations  are  the  following:  First, 
commercially  available  implementations  of  X.400  (based  on  the  1988  recommendation), 
such  as  implemoitations  firom  Hewlett  Packard,  ISODE  Consortium,  and  DEC,  should  be 
obtained  a^  analyzed.  Each  implementation  should  be  analyzed  to  determine  which 
countermeasures  are  met  An  implementation  should  be  selected  for  integration  into  the 
MITRE  network  based  on  die  countermeasures  and  functionality  provided  by  that 
implementation.  If  two  or  mote  implementations  are  very  dose  in  terms  of  countermeasures 
and  functionality,  a  third  criteria  for  sdection  could  be  security  services  provided  since  these 
may  prove  useful  and  may  indicate  how  concerned  the  vendor  was  with  security. 

If  an  essential  countermeasure  is  not  present  in  the  selected  inqilementation,  then  the 
functionality  or  service  resulting  in  a  threat  that  requires  the  countermeasure  must  be 
disabled  and  made  unavailable.  For  all  enabled  services,  the  implementation  that  is 
integrated  into  the  MITRE  network  must  provide  the  essential  countrameasuies  specified  in 
this  bdeting. 
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